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ABSTRACT 


Hie Spacelab Data Processing Facility (SLDPF) has developed expert system 

^° tyP ?f P erforma nce of the quality assurance function of Spacelab 

/or Attached Shuttle Payloads (ASP) processed telemetry data. The SLDPF 
functions include the capturing, quality monitoring, processing, accounting, and 
forwarding of data from Spacelab and ASP missions to various user facilities. The 

° f functional elements: the Spacelab Input Processing System 

(SIPS) and the Spacelab Output Processing System (SOPS) . The two expert system 
prototypes were designed to determine their feasibility and potential in the 
^^ lty T ^ S f U f ariCe ° f processed telemetry data. The SIPS expert system, Knowledge 
oDccrf 111 ^ KSP ^ ' 11363 311 IEM PC/AT with the commercial expert system shell 

. E>ctraction of knowledge from SIPS experts was implemented emulating the 
uties of quality assurance analysts, in an interactive mode, an analyst responds 
o queries resulting in instructions and decisions governing the reprocessing 
re easing or further analysis/ troubleshooting of data. Released data is forwarded 
Z f ^ e f P roce ssing on the SOPS Sperry 1100/82. The data are edited, time 
ordered with overlapping data removed, decommutated, and quality checked before 
shipment. The SOPS QA analysts isolate problems and select the appropriate action: 
ther accept the data or request the data to be reprocessed. The SOPS expert 
system emulates this process by using an expert system shell, CLIPS, and the 
Macintosh personal computer. To date, these prototypes indicate potential 
beneficial results; e,g., increase analyst productivity, decrease the burden of 
lous ana ysis, provide consistent evaluations of data, provide concise 
/^°f 1Cal r ^ cords ' . provide training for new analysts, and expedite the operational 
t-he> i rea3S1 9 ne d Spacelab analysts. The logic implemented in the prototypes, 

innur^S^ 0 " 3 ?L t ? e personal colters utilized, and the degree of accessibility to 
put data have led to an operational configuration. This configuration is 
currently under development and on completion will enhance the efficiency, both in 
time and quality, of releasing Spacelab/ASP data. 
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1 . 0 INTRODUCTON 


Expert system applications in the Information Processing Division were first 
considered for their potential to expedite the SLDPF operations, in particular, the 
quality assurance (QA) and data accounting (DA) analyst functions of both the 
Spacelab Input Processing System (SIPS) and the Spacelab Output Processing System 
(SOPS) . The QA/DA task is often demanding and tediously repetitive. The objective 
of the operational expert systems is to assist the analyst by making decisions and 
suggesting logical analysis paths based on given data quality information. 

The expert system application to assist the QA function of SIPS was assigned to 
Lockheed under the direction of Code 564 ; Lockheed Quality Assurance Analysts 
(QAAs) serve as experts, and system engineers perform the knowledge engineering, 
coding and project management. The application to assist the QA/DA function of 
SOPS was tasked to Code 522, Code 564 and Lockheed; Lockheed QA analysts serve as 
experts, Code 522 performs the knowledge engineering and coding, and Code 564 
provides the project management. Code 564 SLDPF personnel provide the technical 
and overall guidance of the two projects. 

1.1 Implementation 

The strategy formulated to accomplish the prototypes was to use commercial expert 
system shells, code the QA knowledge bases within the shells and implement the 
shells on personal computers. The SIPS expert system effort is identified as 
Knowledge System Prototype (KSP) . The KSP uses OPS 5+ Development System with a 
C language interface installed on an IBM PC/AT. The SOPS expert system (ES) was 
implemented on an Apple Macintosh with CLIPS, an expert system building tool, and 
an interface written by Code 522. 

1.2 Spacelab Data Processing Facility (SLDPF) Overview 

The SLDPF processes experiment payload data from Spacelab and ASP missions. The 
SLDPF functions include the capturing, quality monitoring, processing, accounting, 
and forwarding of data to various user facilities. The SLDPF consists of two major 
functional elements; the Spacelab Input Processing System (SIPS) and the Spacelab 
Output Processing System (SOPS) . See Figure 1. 

During initial SIPS processing, Ku-band channel 2 and/or channel 3 data are captured 
onto high-density tapes (HDTs) . The primary functions in this phase are the real- 
time capture, the monitoring of data for quality and status coordination with the 
Spacelab external interfaces such as the Spacelab Payload Operations Control Center 
(POCC) , the Miss ion Control Center, and the Network elements. After real-time 
capture, the HDTs, including playback and direct access channel data are post- 
processed to produce Spacelab Experiment Data Tapes (SEDTs) and/or Spacelab 
Input/Output Data Tapes (SIDTs) . 

To complete SIPS processing, analysts perform quality assurance analysis by the 
manual evaluation of Spacelab Quality and Accounting Records (SQARs) . This 
analysis is aided with information from several Spacelab reports and logs. The 
results of the QA analysis determines the release of SEDTs, SIDTs and Spacelab 
Quality and Accounting Tapes (SQATs) to the SOPS or to users. 
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Additional data processing is performed by the SOPS. The data are edited, time 
ordered with overlapping data removed, decommutated , and guality checked before 
shipment to users. In a similar manner to the SIPS QA analysis, SOPS QA analysts 
combine information from various summary reports and processed logs to determine 
the guality of data and to decide the data status (release or reprocess) . 

2.0 CONFIGURATION OF PROTOTYPES 

2.1 SIPS Knowledge System Prototype (KSP) 

2.1.1 Overall Description and Function 

The SIPS KSP is designed to emulate the performance of experienced SIPS QAAs in the 
evaluation of Spacelab Quality Control and Accounting Records (SQARs) . This 
function is currently performed through the examination of printouts of the SQAR 
items. 

Initially, three problem areas were identified: gathering the expertise of the 

QAAs, accessing the data which is used in their decision making, and configuring 
the system on an IBM PC AT. See Figure 2 for a diagram of the KSP configuration. 

The first task was the gathering of expertise of the QAAs in the area of SQAR 
analysis to determine if this area is a practical choice for an expert system. It 
became apparent that the expert system concept would work, but the scope of the 
initial effort would have to be restricted due to the extensiveness of the 
application and the limitations of the prototype hardware and software 
configuration- Three stages of analysis were established: initial evaluation, 

comparison of initial and redo runs, and data trends. Each could stand alone 
logically but needed access to the data and decisions of the others. Th ls problem 
was addressed by the use of a database to store data as well as the decisions of 
each stage. The use of the database allowed the expert system to be divided into 
modules to run with the available memory of the prototype configuration. 

The next task addressed was that of accessing the data needed for the decision 
making. As a test, the most used report, the Spacelab Quality Control and 
Accounting Record (SQAR) Report was downloaded from the Gould SEL 32/77 to an IBM 
PC floppy disk. Code was added to the system to read the downloaded report from 
the floppy and to store the data in the database. The test succeeded and dictated 
that, the data access methods should be automated. 

The code surrounding the database continued to grow to include database creation 
and loading, data validation, data maintenance, SQAR selection, expert system 
module selection, and expert system report selection. This module is known as the 
"Front End" because it controls access to and exit from the other expert system 
modules. 

As previously mentioned, the expert system is divided into three parts or stages. 
Each stage operates independently in the expert system environment. As the expe 
system modules run, pertinent data and decisions are written to report l es ro:Tl 
which data base updates and printed summary reports are generated. ^ s P^‘r ei 
Quality Assurance and Accounting Record (SQAR) must first be evaluated (S ge 
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Two evaluated SQARs can be compared and the better one selected (Stage 2) . Trends 
are investigated in Stage 3. 

2.1.2 KSP Knowledge Base 

The rule-based expert system tool 0PS5+ is being used to develop the knowledge base 
for the KSP. The knowledge elements (rules) are in the following form: "IF 

<condition(s)> THEN <action(s) >. " The KSP knowledge base rules are organized in 3 
groups or stages: SQAR evaluation, SQAR comparison, and trends divided (Figure 2) . 

2. 1.2.1 SQAR Evaluation (Stage 1) 

In the SQAR evaluation phase (Stage 1) of the KSP (Figure 3) there are 201 rules. 

The SQAR record produced by the Gould SEL 32/77 is examined and evaluated. . The result 
is a recommendation to accept or reprocess the file in question. The initial SQAR 
record is placed by the SIPS software automatically in one of four categories, 
above criteria, abort, hold, or null. The KSP performs further examination to 
determine how good the data is and if the data can be improved. Analysis occurs 
for each of the four categories and actions are recommended to the analyst. A 
summary file is created during the expert system session and is available to be 
printed at the end of the Stage 1 expert system session. 

CATEGORIES: 

Above Criteria. SQARs marked "above criteria" are examined for coverage and 
recovery. Missing intervals are identified and pursued. The KSP can recommend 
one of three choices: "release (above criteria):, "reprocess (source of 

improved data identified)", or "release (below criteria, best available)". 

Abort. SQARs marked "abort" are examined for coverage, cause of the abort, 
recovery, data quality, and timing. The KSP can recommend one of two results. 

"release (above criteria)", "reprocess (abort)". 

Hold. SQARs marked "hold" cure a mixture of various types of failures. These SQARs 
are examined for coverage, missing intervals, bad records, and duplicate file 
components . The evaluation proceeds depending on the problems of the various file 
components. Recovery, partial (channel) abort, data quality, timing, scheduling, 
and receipt are examined. Several different types of failure can and do occur 
simultaneously. The KSP examines each situation and can recommend "release (above 
criteria)", "reprocess (abort)", "reprocess (source of improved data identified)", 
or "release (below criteria)". 

Null. SQARs marked "null" are one of two types. Either no data was scheduled thus 
creating a deliberate pause, or data was scheduled and not received. The KSP 
examines the timeline for scheduling information and various operators' logs to ^ 
verify data receipt/non-receipt. The KSP can then recommend "release (valid null) , 
or "reprocess (data expected) " . 

2. 1.2. 2 SQAR Comparison (Stage 2) 

In the SQAR comparison phase (Stage 2) of the KSP there ore 130 rules. This stage 
allows SQAR records evaluated from Stage 1 to be compared and evaluated 
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(Figure 4) . The result is the recommendation of the better of the two SQARs. The 
comparisons fall into three categories; two null files, one null file and one 
non-null file, and two non-null files. Extensive analysis is performed on two 
non-null files. A summary report, a detailed report, and a final status report are 
available to be printed at the end of the Stage 2 expert system sessions. 

Two Non-Null Files. The most meaningful comparison is between two files which both 
contain data. These files must have the same number of channels, and the channel 
IDs must correspond. A system of weights assigns values to the data evaluation 
criteria items: total frames, elapsed time, recovery, data quality, timing, frames 

without synchronization errors, and frames without timing errors. Evaluations are 
made on a channel by channel basis followed by a file level recommendation at the 
end. 

One Null File and One Non-Null File. An attempt to compare a null file with a 
non-null file will be decided in favor of the non-null file. The null file is then 
marked as redundant. 

Two Null Files. An attempt to compare two null files is virtually a draw. The 
file with the longer elapsed time is selected for retention, and the file with the 
shorter elapsed time is marked as redundant. 

2. 1.2.3 Trends (Stage 3) 

Trends. Stage 3 of KSP is designed to identify trends from the evaluated SQARs. 
Indication of trends allows for identifying troubleshooting problem areas. For 
example, "Do the majority of data failures occur at a certain transmission rate or 
from a certain piece of equipment?";" Are certain channels failing more than 
others?"; "Are most aborts located in the same channel or within the same user 
group?". As a diagnostic tool, this will be beneficial in solving processing 
problems . 

2.1.3 KSP User Interface 

The KSP Front End interfaces with the user in the form of selection and input 
screens. Required r es ponses are limited to one key-stroke if default values are 
selected (Figure 5) . Page forward and page backward options are provided. Data 
input/viewing screens are provided to allow input and data maintenance (Figure 6) . 

The KSP expert system Stage 1 interfaces with the user in the form of a running 
dialog. It is initiated by loading and initializing the evaluation program after 
entering the OPS 54- environment (Figure 7) . Data not directly downloaded is 
obtained by querying the user. Response requirements are limited to one 
character. During the Stage 1 expert system operation, a summary report is created 
that is printed on request (Figure 8) . The Stage 2 program is loaded and 
initialized to perform the comparison analysis (Figure 9) . This stage operates 
without intervention from the user as the SQAR comparison is executed. Curing 
Stage 2 operation, both a summary report and a detailed report are created and may 
be printed on request (Figure 10 and 11) . 
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Figure 4. KSP SQAR Comparison (Stage 2) 
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****** ***SPACELAB INPUT PROCESSING KNOWLEDGE SYSTEM PROTOTYPE**** ******* * * 
************************STARTUP SCREEN********************************* *** 


* * 

* * 

* TYPE U, S, C, E, P, OR X * 

* * 

* * 

* U (DATA BASE UPDATE PROGRAM) * 

★ * 

* S (SCREENS PROGRAM) * 

* * 

* C (COMPARE PROGRAM) * 

* * 

* E (EXPERT SYSTEMS PROGRAM) * 

* * 

* P (PRINT EXPERT SYSTEM SUMMARY REPORT) * 

★ * 

* X (EXIT TO OPERATING SYSTEM) * 

* * 


************************************************************************** 

Figure 5. KSP Main Menu 


******** SPACELAB INPUT PROCESSING KNOWLEDGE SYSTEM PROTOTYPE ************ 
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Figure 6, KSP File Menu 
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******************************************************************************* 

* Copyright (c) Computer * Thought Corp., 1985, 1986, * 

* Welcome to 0PS5+ * 

* : (load "eval.ops") * 

* ****f ****f****f ****f****f ****j****f ****f****!****|**** i****!**** g****#****. * 

* ****f****f****f****f****f****f****|****g****|****|****|****|****|****£****£ * 

*****£****f****f****f****f****f****| * 

: (watch 0) * 

: (make start) * 

; (run) * 

* 

THEN THE KSP STAGE 1 EXPERT SYSTEM RUNS * 

UNTIL ALL THE PRODUCTIONS * 

HAVE FIRED. * 


WHEN IT IS DONE, THE SYSTEM RESPONDS WITH 
THE MESSAGE: 

No production true 
: (exit) 

Goodbye 

**** ****************************************************************** **** 


Figure 7. 


Load KSP Stage 1 


SQAR EVALUATION 


A0001A/0 1 


FQC - H 

File expected - 1001 seconds. File actual « 716 seconds. File MI « 285 seconds 
ACTION: Process HRM file when received from DACON. 


Channel - 1 CQC * A 

Computed frames » 238607 Recovery - 83.52814 percent. 

FAILURE: Recovery/external. 


ACTION: 

Set 

CQC to 

F. 

** 

REPROCESS ** 

Channel 

ACTION: 

= 14 
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F. 

★ * 

REPROCESS ** 

ACTION: 

ACTION: 

Set 

Set 

PSC to 
FQC to 

REQ. 

F. 

S 3X32S3 

** 

REPROCESS ** 


Figure 8. 


KSP Stage 1 Summary Report 
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* Copyright (c) Computer * Thought Corp. , 1985, 1986. * 

* Welcome to 0PS5+ * 

* : (load "comp. ops" ) * 

* ****#****#****#****#★***#****#****#****#****#***★#****#****#****#****#****:? * 
* a***#****#****#****#****#****#****#****#****#****#****#****#****#****#****:? * 


* ****#****#****§****#****#****#****# * 

* : (watch 0) * 

* : (make start) * 

* : (run) * 

* * 

* THEN THE KSP STAGE 2 EXPERT SYSTEM RUNS * 

* UNTIL ALL THE PRODUCTIONS * 

* HAVE FIRED. * 

* . * 

* . * 

* . * 

* WHEN IT IS DONE, THE SYSTEM RESPONDS WITH * 

* THE MESSAGE: * 

* * 

* No production true * 

* : (exit) * 

* Goodbye * 

* * 


a****************************************************************************** 


Figure 9. Load KSP Stage 2 


SQAR COMPARISON SUMMARY 


CHANNEL ID 

A0003A/01 

B0004B/08 

3 

839.389800 

1355.610000 
* GREATER * 

4 

1331.000000 
* GREATER * 

865.000000 

5 

1103,000000 
* GREATER * 

1093.000000 

Total 

3273.389800 

3313.610000 
* GREATER * 


Figure 10. KSP Stage 2 Summary Report 


DETAILED CHANNEL COMPARISON 

CHANNEL ID 3 

A0003A/ 1 

BOO 04 B/ B 


Value 

Weight 
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Weight 

Total Frames 

142804 

266 

71402 

■ 133 

Delta Time 

1348 

266 

674 

133 

Percent Recovery 

77 
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77 
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QP1 
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150.000000 

99.644000 

150.000000 
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99.644000 

50.000000 

99.644000 

50.000000 

F3 
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— — 

703 

_ _ _ 

Frames Without Sync Errors 

142101 

333 

70699 

166 

F5 

254 

- — 

254 


Frames Without Timing Errors 

142550 

66 

71148 

1 1 

FINAL CHANNEL GRADE 

1331. 
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865.000000 


**** 
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CHANNEL ID 13 

A0003A/ 1 

B0004B/ 8 

Total Frames 

Value 

9573 

Weight 

199 

Value 

9600 

Weight 

200 

Delta Time 

715 

199 

716 

200 

Percent Recovery 

83 

200 

83 

200 

QP1 

94.463000 

149.574800 

99.850000 

150.425200 

QP4 

99.822000 

49.992990 

99.850000 

50.007010 

F3 

530 

— 

520 



Frames Without Sync Errors 

9043 

249 

9080 

250 

F5 

17 

— 

15 


Frames Without Timing Errors 

9556 

49 

9585 

50 

FINAL CHANNEL GRADE 

1095. 

568000 

1100. 

432000 
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*** GREATER *** 


FINAL GRADE FILE 
OPTIONS 


U) 

( 2 ) 


OVERRIDE GRADE 
ACCEPT GRADE 


2426.568000 
*** GREATER *** 


1965.432000 


Figure 11. KSP Stage 2 Detailed Report 
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2.2 SOPS EXPERT SYSTEM (ES) 

2.2.1 Overall Description and Function 

Code 522 developed the knowledge base for the prototype using the rule-based expert 
system language CLIPS. In a rule based ES all knowledge elements are represented 
and processed in the form of If. . . then. . . rules. Hie if is followed by a set of 
conditions and then by a set of actions that will only take place when all the 
conditions following the if are met. 

Hie prototype SOPS Knowledge base can be logically divided into sets called 
knowledge island. Each knowledge island consists of rules to diagnose a problem, 
drive the user interface, and to retrieve data specific to that knowledge island. 
This knowledge base structure simplifies the process of modifying the ES. 

A knowledge island can be modified or replaced to reflect a procedural change in 
SOPS without affecting the other knowledge islands. 

The SOPS prototype ES consists of four knowledge islands: Run Stopped Early, Data 

Gap Between files, Coverage, and Data Quality. The following sections present a 
simplified graph depicting the internal structure of each knowledge island along 
with a brief description. The knowledge islands were implemented in the prototype 
ES only to the detail required to realistically demonstrate an operational SOPS 
ES. The project team will expand each knowledge island for future implementation 
to include particulars uncovered by this prototype ES. 

2.2.2 SOPS ES Knowledge Base 

Run Stepped Early. This knowledge island determines if the run stopped early and 
attempts to determine why (see Figure 12a) . The prototype ES will determine if the 
run stopped early by comparing the processed step time on the SIDT report with the 
run step time on the MIDT report. The QA is required to account for the missing 
data if the time difference is greater than five seconds. If the two stop times 
are within five seconds then the ES can continue to the next knowledge island; if 
not, the ES will attempt to determine the cause for the missing data. The ES will 
first check if the time from the last major frame used in the file is the same as 
the run stop time on the MIDI report for an indication of a possible run abort 
during processing. This condition is typically caused by a hardware problem such 
as a bad tape drive. If the times are the same, the ES will prompt the QA to look 
in the SIDT database and the card deck to check if the correct files were used for 
this run. 

Data Gap Between Files. This knowledge island determines if there is missing data 
between two files in the run (see Figure 12b) . The prototype ES accomplishes this 
by comparing the stop time of the first file in the run with the start time of the 
next file of the same type. The two types of files, high data rate and low data 
rate, are not compared to each other. The ES will continue to compare the stop and 
start time for each successive file of the same type. If no gape greater than five 
seconds are found between the files, the ES can continue to the next knowledge 
island. 
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It 


In the event a gap is found, the ES will check if the gap is listed on the 
Permanently Hissing Interval (FMI) List; if not, the ES will prompt the QA to 
determine if the data is available in SIPS by checking the Event Summary Repo 
(ESR) Configuration Controller (CPC) log, Playback Summary leg, and Data 
Processing sSnSry Report (DPSUM) . The QA will request the missing data records, 
available, to be placed on a Spacelab quality control and accounting tape (SQAT) , 
the tape loaded into the SOPS database, and the run reprocessed. 

If the data is not available, the ES will prompt the QA to determine if the 1S 
an undocumented ME. If the QA confirms an undocumented EMI, the ES will inse 
th© FMI on the FMI List end continue. 

Coverage. This knowledge island determines if there is missing data within a file 
in the run (see Figure 12c) . The first step the ES takes is to calculau- Jne mr 
frame coverage for the time between the channel start and stop times for each 
file. If the minor frame coverage for each file is greater than 98 precenu, Ji_ rS 
can continue to the next knowledge island. 

If the minor frame coverage is less than 98 percent, the ES will prompt the QA to 
check the ESR and CFC log for comments about gaps and dropouts in da^a. In e 
case where gaps, including ROs, are noted in the logs, the ES will recalculate the 
minor frame coverage over the file times containing the gap. If the minor frame 
coverace is still below 98 percent, the ES will prompt the QA to check on t.e hig. 
Data Rate Recorder (HDRR) for the missing data. 

Data Quality. This knowledge island is concerned with the quality of the data and 
if it can be improved (see Figure 12d) . The ES determines the quality of the da^a 
by calculating the percentage of error flags set. If the percentage o error ^ g 
is greater than two percent, the ES will attempt to check the file qu lty • 

If SIPS did not release the data below criteria as the best available, the _S l 
prompt the QA to check the ESR and CFC log for comments about dropouts or poor 
data. Where no explanation for the poor quality is found in the legs, the ES ll 
prompt the QA to determine if the data can be cleaned up before proceeding. 

2.2.3 ES User Interface 

The SOPS ES prototype uses many of the features that are standard for applications 
running 5 on the° Apple 6 Macintosh . The features . include the use of multiple widows, 
pull-down menus, and dialog taxes. Figure 13 is an example of the default scresi 
layout used in the prototype. 

Dialog boxes and windows may contain buttons, scroll bars, or space for the analyst 
to type in additional information called a text field. Whenever possible, the ES 
default value for the text fields. If the analyst chafes the value 
a text field, the ES should perform consistency checks and prevent the analyst, fr 
entering 1 inval id values. Forexample, if a text field requires a nimtar, the 
prototype will only allow digits to be typed in. The consistency checking on the 
operational ES should be expanded to confirm that the value, as l is ing yped 
in7is within the correct range and notify the analyst if it is not. 

2. 2. 3.1 Windows 

The primary windows that will be viewed by the QA analyst are ^ 

SSef SS^bnclusion windows. The Transcript window maintains a log of the ES 
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session that can be printed upon completion. This log will contain all questions 
a s ked by the prototype ES and the analyst's responses, all recommendations from the 
ES, and any comments the analyst wishes to add. The Time Line window display's the 
run in a graphical format with the expert system's current focus of attention 
flagged. The Conclusion window displays the conclusions reached (rules fired) 
by the ES. 

The screen also has the SIDI Report, SIDT/MIET Report, MIDT Report, and preview 
windows. The report windows contain detailed data about the run being evaluated. 
The preview line is a special window that displays help information related to the 
current position of the mouse. 

The QA analyst can customize the window arrangement on the screen with the mouse by 
positioning the cursor on the title bar of a window, pressing and holding the mouse 
button down, moving the mouse to a new position (the window will follow) , and 
releasing the button (this is referred to as "dragging" an object) . 

Many of the windows used in the prototype have scroll bars that the analyst can use 
to change the current view of the contents in the window. Scrolling can only be 
accomolished in an active window with the scroll bars visible. To make an inactive 
window active, the analyst positions the cursor in the window and presses and 
releases the mouse button (referred to as "clicking" on an object) . In addition, 
some of the windows contain a size box and a zoom box for resizing an active 
window. The analyst simply drags the size box with the mouse to reshape the 
window, or clicks in the zocm box to expand the window to the full size of the 
screen. Clicking in the zoom box again will return the window to its original size 
and position. The QA analyst can use this feature to get a more comprehensive view 
of a window and then return without disrupting the layout of the screen. 

2 . 2 . 3 . 2 Menus 

Displayed at the top of the prototype screen is the menu bar (see Figure 14) . It 
contains the titles of the menus available. To choose a command from the menu, the 
analyst positions the cursor over the menu title and holds the mouse button down. 
While holding down the mouse button, the analyst moves the cursor down the. 
displayed menu. As the cursor moves to each enabled command, the command is 
highlighted. When the analyst releases the button on a highlighted command, 
that command is selected. A shortcut for selecting some commands is holding 
down the Command key in combination with another key called the keyboard 
equivalent. Commands that have keyboard equivalents list them in the menu. 

The (Apple) menu contains up to 15 desk accessories such as a calculator or a clock 
that the analyst can use during an evaluation run. Choosing any of the desk 
accessories causes that acceessory to appear on the screen. The analyst can use 
the Edit menu to cut, copy, and paste the information in most desk accesories. 
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The File menu contains the following commands for processing a run file: 

Load Run. .. - prompts the analyst for a run number and load the run into the ES ; 

Print - prints the results of the ES run evaluation (not implemented in the 

prototype) ; 

Save - saves the results (not implemented in the prototype) ; 

QA/DA - starts or resumes the evaluation of a run; if the analyst has stopped the 
evaluation before completion, this command in the menu will be 
Resume QA/DA; and 
Quit - quits the SOPS ES. 

The Edit menu allows the analyst to perform the standard Macintosh cut, copy, 
paste, and cl ear commands on text windows and desk accessories. The analyst can 
copy and paste data from the Report windows or conclusions from the Conclusion 
window into the Transcript window. 

The View menu contains the following commands: 

EMI List - displays the EMI List window and allows the analyst to add a EMI; 

Run History - displays the processing history of a run (not implemented in the 
prototype) ; This might take the form of the last Transcript file or a summary of 
previous ES evaluations; 

Mission History - displays a summary window of statistics such as the number of 
good and bad runs over the length of the mission (see Figure 15a) , and 
Mission Parameters - displays the Mission Parameters window that allows the analyst 
to change mission specific parameters or evaluation criteria before starting the ES 
evaluation (see Figure 15b) . 

The Windows menu contains a list of all the windows on the screen. A window can be 
selected from this list to make it active and redrawn as the front window. The 
Windows menu also contains a Clean Up command which will restore the default layout 
of the windows on the screen. 

2 . 2 . 3 . 3 Dialog Boxes 

The prototype ES uses dialog boxes to prompt the QA analyst for more information or 
to display . a recommendation . In the prototype ES, dialog boxes are used in two 
forms: modal and modeless. A modal dialog box is one that the analyst must 
acknowledge before doing anything else. Since modal dialog boxes restrict the 
analyst 1 s options , the prototype only uses them for messages requiring the 
attention of the analyst. Figure 16 is an example of a modal recommendation dialog 
box. A modeless dialog box allows the analyst to perform other operations before 
responding to the dialog box. 

The information in a dialog box is designed to be as concise as possible so an 
experienced QA analyst is not burdened with lengthy messages and explanations. For 
this reason, an Info button is available for less experienced analysts. The 
analyst can click on the Info button to get an additional page or pages of 
information if needed. The additional information might include a more detailed 
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explanation, or - in the case of a question dialog box, the information might specify 
where to get the data to complete the dialog box. 

Many of the dialog boxes in the prototype have a bold outlined default button. The 
default button is always selected if the analyst presses the Return or Enter key on 
the keyboard. The advantage of a default button is that the analyst does not have 
to move his hands off the keyboard to respond to the dialog box. If a dialog box 
does not have a default button (bold outlined button) , pressing the Return or Enter 
key does not have any effect. 

3.0 BENEFITS OF PROTOTYPES 

The Spacelab expert system prototypes offer many benefits. They are fast. They 
are consistent. They make the expertise of the most experienced staff members 
available to all. The prototypes can act as training tools when refined to a detailed 
level. As they are developed, they identify ways in which current procedures could 
be further automated to increase accessibility to information and improve processing 
speed as well as to decrease the monotony of repetitious taste. They also identify 
ar ea s in their cwn operation that should be streamlined to make the expert system 
concept not only workable but practical. 

4.0 OPERATIONAL CONFIGURATION 

The goal of the Spacelab prototype expert systems is to define the design and the 
configuration for expert systems in the mission environment. These new operational 
expert systems will be larger, more efficient, and more automatic, incorporating > 
the capabilities indicated by but not present in the prototypes. Both the SIPS and 
SOPS operational expert system configurations will make use of the same hard'.-.are 
and software for consistency (see Figure 17) . It is planned that the initial 
configuration will be operational by July 1988, in time to support ASTRO-1, the 
several scheduled SLDPF missions in the post— Challenger period. 
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FINAL EXPERT SYSTEM CONFIGURATION 



QA - Quality Assurance 

ES * Export Systom 

MIS * Management Information System 


Figure 17. Operational Configuration 
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